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Common Practices for C Programming 
Abstract 


With widespread use, a number of common practices and conventions have evolved to help 
avoid errors in C programming. These are both a demonstration of applying good software 
engineering principles to a language, and an indication of C's limitations. Although few are 
universally used and some are controversial, each enjoys wide use. 
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Rezumat 


Odată cu utilizarea pe scară largă, o serie de practici şi convenţii comune au evoluat pentru 
a ajuta la evitarea erorilor în programele C. Acestea sunt simultan o demonstrație a aplicării 
bunelor principii de inginerie software într-un limbaj, și o indicație a limitărilor C. Deși puţine 
sunt utilizate universal, iar unele sunt controversate, fiecare dintre acestea se bucură de o utilizare 
largă. 
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PRACTICI COMUNE PENTRU PROGRAMAREA ÎN C 


Odată cu utilizarea pe scară largă, o serie de practici şi convenţii comune au evoluat pentru 


a ajuta la evitarea erorilor în programele C. Acestea sunt simultan o demonstrație a aplicării 


bunelor principii de inginerie software într-un limbaj, şi o indicație a limitărilor C. Deşi puține 


sunt utilizate universal, iar unele sunt controversate, fiecare dintre acestea se bucură de o utilizare 


largă. 


Matrice multidimensionale dinamice 


Deşi matricele unidimensionale sunt uşor de creat dinamic folosind malloc, iar matricele 


multidimensionale cu dimensiuni fixe sunt uşor de creat folosind caracteristica de limbaj 


încorporată, matricele multidimensionale dinamice sunt mai complicate. Există o serie de moduri 


diferite de a le crea, fiecare cu compromisuri diferite. Cele mai populare două moduri de a le crea 


sunt: 


Ele pot fi alocate ca un singur bloc de memorie, la fel ca matricele multidimensionale 
statice. Acest lucru necesită ca matricea să fie dreptunghiulară (adică sub-tabele de 
dimensiuni mai mici sunt statice și au aceeași dimensiune). Dezavantajul este că sintaxa 
declarației pointerului este puţin complicată pentru programatorii începători. De 
exemplu, dacă s-ar dori să creeze o matrice de întregi de 3 coloane şi rânduri rows, cineva 
ar scrie 


int (*multi array) [3] = malloc(rows * sizeof(int[3])); 


(Reţineţi că aici multi array este un pointer către o matrice de 3 întregi.) 


Din cauza interschimbabilităţii matrice-pointer, puteți indexa acest lucru la fel ca și 


matricele multidimensionale statice, de ex. multi array[5] [2] este elementul de pe al 6-lea rând 


şi pe a 3-a coloană. 


Matricele multidimensionale dinamice pot fi alocate prin alocarea mai întâi a unei 
matrice de pointeri, apoi alocarea submatricelor şi stocarea adreselor acestora în matricea 
de pointeri.! (Această abordare este cunoscută și ca vector Iliffe). Sintaxa pentru 
accesarea elementelor este aceeași ca şi pentru tablourile multidimensionale descrise mai 
sus (chiar dacă sunt stocate foarte diferit). Această abordare are avantajul capacităţii de 
a realiza matrice neregulate (adică cu sub-matrice de diferite dimensiuni). Cu toate 
acestea, de asemenea, utilizează mai mult spațiu şi necesită mai multe niveluri de 
direcționare indirectă pentru a indexa şi poate avea performanţe mai slabe ale memoriei 
cache. De asemenea, necesită multe alocări dinamice, fiecare dintre acestea putând fi 
costisitoare. 


Pentru mai multe informații, consultați întrebările frecvente comp.lang.c, întrebarea 6.16. 


Adam N. Rosenberg. [http://www.the-adam.com/adam/rantrave/st02.pdf "A Description of One 


Programmer”s Programming Style Revisited"]. 2001. p. 19-20. 
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În unele cazuri, utilizarea tablourilor multidimensionale poate fi abordată cel mai bine ca 
o matrice de structuri. Înainte ca structurile de date definite de utilizator să fie disponibile, o tehnică 
comună a fost definirea unei matrice multidimensionale, în care fiecare coloană conţine informaţii 
diferite despre rând. Această abordare este folosită frecvent şi de programatorii începători. De 
exemplu, coloanele unei matrice de caractere bidimensionale pot conține nume, prenume, adresă 
etc. 

În astfel de cazuri, este mai bine să definiţi o structură care conţine informaţiile care au fost 
stocate în coloane şi apoi să creaţi o matrice de pointeri către acea structură. Acest lucru este valabil 
mai ales atunci când numărul de puncte de date pentru o anumită înregistrare poate varia, cum ar 
fi melodiile dintr-un album. În aceste cazuri, este mai bine să creaţi o structură pentru album care 
să conțină informaţii despre album, împreună cu o matrice dinamică pentru lista de melodii de pe 
album. Apoi, o serie de pointeri către structura albumului poate fi folosită pentru a stoca colecția. 


e Un alt mod util de a crea o matrice multidimensională dinamică este aplatizarea şi 
indexarea manuală a matricei. De exemplu, o matrice bidimensională cu dimensiunile x 
ŞI y are elemente x*y, prin urmare poate fi creată de 


int dynamic multi arraylx*y]; 
Indexul x este puţin mai complicat decât înainte, dar poate fi obținut totuși prin y*1+j. Apoi 


accesaţi matricea cu 


static multi array[i][)]; 
dynamic multi arrayl[y*i+)]; 


Mai multe exemple cu dimensiuni mai mari: 


W 
W 


int diml 
int dim? 
int dim3 


[ 
[ 
[ 
int dim4[ 


w% (x*i+))+k] // index is k + w*] + wYx*i 
w* (x% (y%i+])+k)+1] // index is w*xăyti + wăxtj + w*k + 1 


Reţineţi că w*(x*(y*%i+j)+k)+ este egal cu w*x*y*i + w*x*j + w*k + 1, dar utilizează mai 
puţine operaţii (metoda lui Horner ). Foloseşte acelaşi număr de operaţii ca şi accesarea unei 


matrice statice prin dim4[1][)][k][1], deci nu ar trebui să fie mai lent de utilizat. 
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Avantajul utilizării acestei metode este că matricea poate fi trecută liber între funcții fără a 
cunoaşte dimensiunea matricei în momentul compilării (deoarece C o vede ca o matrice 
unidimensională, deşi este încă necesară o modalitate de a trece dimensiunile), iar întreaga matrice 
este contiguă în memorie, deci accesarea elementelor consecutive ar trebui să fie rapidă. 


Dezavantajul este că poate fi dificil la început să te obişnuieşti cu modul de indexare a elementelor. 


Constructori şi destructori 


În majoritatea limbajelor orientate pe obiecte, obiectele nu pot fi create direct de către un 
client care doreşte să le folosească. În schimb, clientul trebuie să ceară clasei să construiască o 
instanță a obiectului folosind o rutină specială numită constructor. Constructorii sunt importanți 
deoarece permit unui obiect să impună invarianţi cu privire la starea sa internă pe toată durata de 
viață. Destructorii, chemaţi la sfârşitul duratei de viaţă a unui obiect, sunt importanți în sistemele 
în care un obiect deţine acces exclusiv la o anumită resursă şi este de dorit să se asigure că 
eliberează aceste resurse pentru a fi utilizate de către alte obiecte. 

Deoarece C nu este un limbaj orientat pe obiecte, nu are suport încorporat pentru 
constructori sau destructori. Nu este neobişnuit ca clienţii să aloce și să inițializeze în mod explicit 
înregistrări şi alte obiecte. Cu toate acestea, acest lucru duce la un potenţial de erori, deoarece 
operațiunile asupra obiectului pot eşua sau se pot comporta imprevizibil dacă obiectul nu este 
inițializat corespunzător. O abordare mai bună este să aveţi o funcție care creează o instanță a 
obiectului, eventual luând parametrii de inițializare, ca în acest exemplu: 
struct string | 

size _t size; 
char *data; 
); 


struct string *create string(const char *initial) ( 
assert (initial != NULL); 
struct string *new string = malloc(sizeof (*new string)); 
if (new string != NULL) f 
new string->size = strlen(initial); 
new string->data = strdup(initial); 


) 


return new string; 


In mod similar, dacă este lăsat la latitudinea clientului să distrugă obiectele corect, acesta 
poate să nu facă acest lucru, provocând scurgeri de resurse. Este mai bine să aveţi un destructor 


explicit care este întotdeauna folosit, cum ar fi acesta: 
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void free string(struct string *s) [ 


assert (s != NULL); 
free(s->data);  !!/* free memory held by the structure */!! 
free (s); 11/* free the structure itself */!! 


Este adesea util să combinaţi destructorii cu indicatorii eliberați nuli. 

Uneori este util să ascundeți definiția obiectului pentru a vă asigura că clientul nu îl alocă 
manual. Pentru a face acest lucru, structura este definită în fișierul sursă (sau într-un fişier antet 
privat care nu este disponibil utilizatorilor) în loc de fişierul antet şi o declaraţie este pusă în fişierul 
antet: 
struct string; 


struct string *create string(const char *initial); 
void free string(struct string *s); 


Pointeri eliberați nuli 


După cum s-a discutat mai devreme, după ce free () a fost apelat pe un pointer, acesta 
devine un pointer suspendat. Mai rău, majoritatea platformelor moderne nu pot detecta când este 
folosit un astfel de pointer înainte de a fi reatribuit. 

O soluţie simplă la aceasta este să vă asiguraţi că orice pointer este setat la un pointer nul 
imediat după ce a fost eliberat?: 


free (p); 
p = NULL; 


Spre deosebire de pointerii suspendaţi, o excepţie hardware va apărea pe multe arhitecturi 
moderne când un pointer nul este dereferențiat. De asemenea, programele pot include verificări de 
eroare pentru valoarea nulă, dar nu pentru o valoare a pointerului suspendat. Pentru a vă asigura 


că se face în toate locaţiile, poate fi utilizată o macrocomandă: 


define FREE (p) do [ free(p); (p) = NULL; ) while(0) 


(Pentru a vedea de ce macro-ul este scris în acest fel, se pot folosi convențiile Macro.) De 


asemenea, atunci când se utilizează această tehnică, destructorii ar trebui să aducă la zero pointerul 


2 comp.lang.c FAQ list: "Why isn't a pointer null after calling free?" mentions that "it is often useful to set 
[pointer variables] to NULL immediately after freeing them". 
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pe care le-au trecut, iar argumentul lor trebuie să fie transmis prin referință pentru a permite acest 


lucru. De exemplu, iată destructorul de la Constructori și destructori actualizat: 


void free string(struct string **s) 4 


assert (s != NULL &&  *s != NULL); 

FREE ((*s)->data); 11/* free memory held by the structure */!! 
FREE (*s) ; 11/* free the structure itself */!! 

* s=NULL; 11/x zero the argument */!! 


Din păcate, acest idiom nu va face nimic altor pointeri care ar putea indica memoria 
eliberată. Din acest motiv, unii experţi C consideră acest idiom ca fiind periculos din cauza creării 


unui fals sentiment de securitate. 


Convenții macro 


Deoarece macrocomenzile preprocesorului din C funcționează folosind înlocuirea simplă 
a simbolurilor, ele sunt predispuse la o serie de erori de confuzie, dintre care unele pot fi evitate 
urmând un set simplu de convenţii: 


1. Plasarea parantezelor în jurul argumentelor macro ori de câte ori este posibil. Acest lucru 
asigură că, dacă sunt expresii, ordinea operaţiilor nu afectează comportamentul expresiei. 
De exemplu: 
a. Greşit: țdefine square (x) x*x 
b. Mai corect: define square (x) (x)* (x) 
2. Plasarea parantezelor în jurul întregii expresii dacă este o singură expresie. Din nou, acest 
lucru evită schimbările de sens datorită ordinii operaţiilor. 
a. Greşit: țdefine square (x) (x)* (x) 
b. Mai corect: define square (x) ((x)*(x)) 
c. Periculos, amintiţi-vă că înlocuieşte cuvintele din text. Să presupunem că codul tău 
este square (x++), după invocarea macro-ului x va fi incrementat cu 2 
3. Dacă o macrocomandă produce mai multe instrucţiuni sau declară variabile, aceasta poate 
fi înfăşurată într-o buclă do ! ... ! while(0), fără punct şi virgulă de sfârşit. Acest lucru 
permite macrocomenzii să fie folosită ca o singură instrucţiune în orice locaţie, cum ar fi 
corpul unei instrucțiuni i f, permițând totuși plasarea punctului şi virgulă după invocarea 
macrocomenzii fără a crea o instrucțiune nulă*%5%5. Trebuie avut grijă ca orice variabilă 
nouă să nu mascheze potenţial porțiuni din argumentele macrocomenzii. 
a. Greşit: țdefine FREE(p) free(p); p = NULL; 
b. Mai corect:: taefine FREE (p) do ( free(p); p = NULL; ) while(0) 


"comp.lang.c FAQ: What's the best way to write a multi-statement macro?”. 
"The C Preprocessor: Swallowing the Semicolon" 

"Why use apparently meaningless do-while and if-else statements in macros?" 
"do (...+ while (0) in macros" 

"KernelNewbies: FAQ / DoWhile0". 

"PRE10-C. Wrap multistatement macros in a do-while loop”. 


o Aa Nu pp ww 
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Evitarea folosirii unui argument macro de două sau mai multe ori în interiorul unei 
macrocomenzi, dacă este posibil; acest lucru cauzează probleme cu argumentele macro 
care conţin efecte secundare, cum ar fi atribuirile. 

Dacă o macrocomandă poate fi înlocuită cu o funcție în viitor, luaţi în considerare 
denumirea acesteia ca o funcţie. 

Prin convenție, valorile preprocesorului şi macrocomenzile definite de taefine sunt 
denumite cu toate literele mari”10111215, 

Există un număr mare de instrucțiuni pentru stilul C. 


„Ghidurile de stil C şi C++” de Chris Lott enumeră multe ghiduri de stil C populare. 


Motor Industry Reliability Association (MISRA) publică „MISRA-C: Ghid pentru 
utilizarea limbajului C în sistemele critice”. 
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